
\lhead[\chaptername~\thechapter]{\rightmark}


\rhead[\leftmark]{}


\lfoot[\thepage]{}


\cfoot{}


\rfoot[]{\thepage}


\chapter{Einleitung}
In den vergangenen Jahren hat der Einsatz von vernetzten Desktop-Anwendungen und Webanwendungen, die sensible Daten für Wirtschaft und Gesellschaft verarbeiten, stark zugenommen. Insbesondere die Tatsache, dass immer immer mehr Daten einer breiten globalen Öffentlichkeit ausgesetzt sind, verdeutlicht die Notwendigkeit, diese Daten entsprechend zu schützen.
Die gängigsten Szenarien zielen auf intrusive Angreifer, die im hohen Ausmaß Einfluss auf den Kontrollfluss der Anwendung nehmen. In diesen Szenarien schickt der Angereifer aktiv speziell gefertigte gemeine Anfragen, welche vom Empfänger, der angriffsempfindlichen Anwendung,  als Befehl aufgenommen und ausgeführt werden. Großer Beliebtheit erfreuen sich hier Buffer Overflows und SQL Injections. Sobald diese Angriffe erfolgreich durchgeführt worden sind, kann der Angreifer den weiteren Kontrollfluß der Anwendung zu seinen Gunsten manipulieren: Die Vertraulichkeit, Integrität und Authentizität der Daten kann nicht mehr sichergestellt werden. 
%Networked software applications and a growing number of web applications process information that is critical for companies, the economy, and for our social lives. As the Internet grows, more and more of these applications are directly connected to the Internet and are thus globally accessible. The fact that critical information is processed in applications that are exposed to the Internet underlines the necessity to protect this information. Given the steady stream of pressarticles about security breaches in the last decade (e.g. [BHH+ 11]), it becomes clear that many software applications are attacked on a daily basis. The most common attack scenarios focus on an intrusive attacker that gains extensive control of the targeted application. In these scenarios, the attacker sends specially crafted rogue requests to the vulnerable application which interprets parts of the requests as commands and executes them. Popular examples for these attacks are Buffer Overflow attacks [Ale96] or SQL-Injection attacks [rai98]. If any of these attacks succeeds, the attacker can change the original control flow of the application in a way that he can breach the confidentiality, integrity, or availability of critical information.
%Side channel attacks are different to Buffer Overflow or SQL-Injection attacks because the attacker is either passively listening to network traffic or only sending benign requests to the targeted application. Just from observing the behaviour of the application, the attacker infers sensitive information, thus breaching the confidentiality1 of critical information. The fact that the behaviour of the application depends on sensitive information forms a side channel vulnerability. Side channel vulnerabilities appear unintentionally because they were accidentally created during implementation. They are also hidden channels as a naive observer is unlikely to notice them because of the obscure information encoding of the chan
Seitenkanalangriffe unterscheiden sich elementar von Buffer Overflows oder SQL-Injektions Angriffen, da bei einem Seitenkanalangriff der Angreifer sich entweder passiv verhält und nur "lauscht" oder nur gewöhnliche d.h. gutartige Anfragen an das Zielsystem stellt. Sensible Daten werden ferner allein durch Beobachtung des Verhaltens der Anwendung gewonnen. Die Tatsache, dass das Verhalten der Anwendung von den sensiblen Daten abhängig ist, macht die Schwäche für den Seitenkanalangriff aus.

\section{Time is on my side, yes it is}
%Diss Schinzel
%In this thesis, we focus on side channels appearing in the content and the timing behaviour of networked software applications. As simplified example, Figure 1.1 shows how the attacker can learn confidential information by exploiting a timing side channel. In this case, the confidential information is whether a given user name exists or not. The attacker sends a login request with a user name and an arbitrary password at time t0 and measures the time it takes for the response to arrive. The attacker expects the server to return an error message because the password was most certainly wrong. However, the attacker can learn if the user name is valid because the server only then checks the password if the user name is correct. Otherwise, the server returns an error message without checking the password. 
In meiner Arbeit befasse ich mich mit Seitenkanalangriffen, die sich Rechenzeiten zu Nutze machen, sogenannte Timing-Attacken. Ein Timing-Angriff funktioniert in etwa wie in folgender Abbildung:
\begin{figure}[h]
\includegraphics[width=1.0\textwidth]{img1/abb_schinzelsidechannel}
\end{figure}
In unserem Beispiel ist die sensible/vertrauliche Information die, ob ein Benutzer im System existiert oder nicht. Der Angreifer tätigt ein Loginversuch mit einem Benutzernamen und einen x-beliebigen String als Passwort zum Zeitpuntk $t_0$ und misst die Zeit, die es dauert bis die Antwort des entfernten Systems eingegangen ist. Der Angreifer geht hierbei davon aus, dass es sich um eine Fehlermeldung handelt, da das Passwort falsch war. Jedoch ist der Angreifer in der Lage in Erfahrung zu bringen, ob der Benutzer existiert, da der Server, nur dann das Passwort auf Richtigkeit prüft, wenn der Benutzer existiert. Ansonsten gibt der Server eine Fehlermeldung zurück, ohne das Passwort zu prüfen.
Da das Überprüfen des Passwort aufgrund eines Hash-Vorgangs einige Zeit in Anspruch nimmt, kann der Angreifer    . Wenn die Antwort des Servers zum Zeitpunkt $t_1$ eintrifft, weiß der Angreifer, dass der Benutzer nicht existiert. Andernfalls, wenn die Antwort zum Zeitpunkt $t_2$ eintrifft und somit das Passwort geprüft worden ist, bringt der Angreifer in Erfahrung, dass der Benutzer auf dem Server existiert.
%As checking the password takes some time, the attacker can conduct the side channel attack as follows: if the response returns at time t1 , the attacker knows that the user does not exist. Else, the attacker learns that the user name was valid, because the response arrives at a later time t2, suggesting that the password was checked. We define side channel attacks as follows:


\section{Fragestellungen}

\section{Bisherige Arbeiten} 




